Previous Section   Next Section

4.2 Implementing a Service Desk infrastructure

Designing your Service Desk support infrastructure correctly is critical to success and should be done as a formal business improvement project with clear ownership, defined business goals, responsibilities, deliverables and management commitment.

However, before even starting to identify your needs, consider the basic premise of what you want to achieve. This is an opportunity to re-evaluate the whole way you have, to date, delivered service. Don't just think of automating current manual processes, using staff in the same way. Consider a rethink and redesign of the processes and activities in order to increase productivity, add value, reduce cost and improve the Customer's perception. Consider the question 'If this was your business, would you organise it, resource it, and run it, this way?'

4.2.1 Staff resourcing

An operational service needs to be maintained on a daily basis. It is not therefore always practical to expect 'business as usual' and still implement a successful service-improvement project. Additional resource is generally required to assist during the project set-up phase.

A major consideration is the skill sets available within your organisation to deliver this project successfully. It is essential that the project team involved has proven Service Management and implementation skills.

Where 'business as usual' cannot be maintained due to implementation of a service-improvement project, it is important, as well as acquiring additional resource, to communicate this fact to the Customer.

In situations where skilled resource is a problem, the usage of contract and outsourced services should be considered. Utilising and training by internal resources should also be investigated, for example by transferring staff from other teams in the department or releasing staff from non-critical projects.

4.2.2 Target effectiveness metrics

Decide and set targets for a manageable number of objective metrics for the effectiveness of the Service Desk. This task requires careful consideration, because the post-implementation and subsequent ongoing reviews will compare these targets with reality. Take the metrics into account during the technology-tool selection and design stages.

Guidelines for setting metrics include the following:

In relation to SLA criteria, and subject to request volumes, baseline data should be collected for a period of approximately two months to ensure a viable sample is available for analysis. It is critical to understand the levels of service you are currently providing with the current resources available before making changes.

4.2.3 Key considerations

Here are some key points for consideration when setting up a Service Desk:

4.2.4 Selecting the right Service Desk structure

The type of Service Desk, skill level and organisational structure you choose is dependent on a number of important factors. There is no 'universal' configuration to suit all. As your business changes, so will your support operation; therefore flexibility is crucial to support future growth.

4.2.5 Types of Service Desk structure

Three types of structures should be considered for optimum usage:

  1. local Service Desk
  2. central Service Desk
  3. virtual Service Desk.

These are each described in more detail below.

4.2.6 Local Service Desk considerations

Traditionally, organisations have created local support desks (see Figure 4.7) to meet local business needs. This is practical until multiple locations requiring support services are involved. Duplicating skills and resources will become very expensive. If your organisation is maintaining several local support desks, it is important that operational standards are introduced.

Figure 4.7 - Local Service Desk

Figure 4.7 - Local Service Desk

Considerations for implementing a local Service Desk structure include:

4.2.7 Central Service Desk considerations

In this arrangement, all service requests are logged to a central physical location, as shown inFigure 4.8. If your organisation has multiple locations, having a central support service has major business benefits, including:

Figure 4.8 - Centralised Service Desk

Figure 4.8 - Centralised Service Desk

4.2.8 Virtual Service Desk considerations

To a great extent the physical location of the Service Desk and the associated services are immaterial. This is largely due to advances in network performance and telecommunications. The 'Virtual Service Desk' (Figure 4.9) can be situated and accessed from anywhere in the world.

If your organisation has multiple locations, having a single global support service has major business benefits, including:

However, the prime operational restriction to the Virtual Desk is the need for a physical presence by a specialist or replacement engineer.

Figure 4.9 - Virtual Service Desk

Figure 4.9 - Virtual Service Desk

Considerations when setting up a Virtual Service Desk include the following:

4.2.9 Service Desk Configuration considerations

The criteria to decide on the best configuration for your organisation are varied, but should include:

4.2.10 Global 'follow the sun' support

When an organisation is providing 24-hour support, or extended cover, around the globe, the following points should be considered:

Design Consideration

Furthermore, if you wish to pass requests between Service Desks or merge them in the future, consider agreeing unique identification, prefixing and number ranges for your global network, so as to avoid the problems that might arise if you have requests with the same number.

4.2.11 Incident classification

Classification is one of the most important attributes of an Incident to get right. Classification is used to:

The final classification(s) may vary from that initially reported. The Customer may have reported a 'symptom' of an Incident and not necessarily the root Problem. The levels of classification will vary depending on the detail required. For example, a top-level classification of 'Word Processing', or 'Payroll Service' is adequate for an overview; however, greater detail may then need to be obtained in areas such as:

When an Incident is completed, it is beneficial, for certain types of request, to enter a 'closure classification' or 'closure code'. This should state the actual cause, a summary conclusion, or a specific course of action. Examples include:

Detailed classification will ensure more effective management information.

4.2.12 Classification Process Review

The management information provided by reporting against classification should be reviewed regularly to ensure that meaningful, up-to-date, data is returned. However, one should not overcomplicate this process by adding too many classifications initially, because this may cause confusion when support staff are registering Incidents. It is also recommended that standard classifications such as 'Unknown' or 'Unable to classify' be included, as this will prevent support staff from making a 'best guess'. These Incidents can later be reviewed and classifications generated/amended, if required. In general, it is best to start simple and expand as business needs demand it.

Start simple and expand as the business needs demand it.

Previous Section   Next Section